1. Field of the Invention
This invention relates generally to the use of data-type definition language to identify types of electronic files and provide functional instructions for the processing of such files. The invention further relates to systems for managing workflow processes over a communication network.
2. Description of the Related Art
Present systems for enhancing business workflow, whether intra-business or inter-business are generally limited to the scope of the information subject matter they were designed to address. For example, some accounting systems have the ability to import information from external sources in order to manipulate it according to the processes and constructs of that system. Some systems have integrated even more categories of business information to provide more comprehensive tracking and business management capabilities for the user. For example, available “enterprise software” applications track not only accounting information, but also sales, inventory, pricing, shipping, and other information in a single, integrated environment.
The limitation of these systems is that information provided to these systems must be in a format that is recognizable and manipulable by the systems. In many instances, the information must be entered in a system specific environment in order to be recognized and processed by the system. Further, many of the more complex systems integrating various and previously disparate functions require the components of the systems to constantly monitor the information flowing through the system to determine whether that information is relevant to that component and therefore whether that component must then perform some function.
Many of these systems take the form of a hub and spoke network as seen in prior art FIG. 6. For example, an enterprise integration system could have a hub for routing information from one application to the others on the network. A hub contains multiple ports and is used to connect segments of the network. When an information packet arrives at one port, it is copied to the other ports so that all enterprise applications on the network can see all packets. A hub serves simply as a conduit for the data, enabling it to go from one application on the network to another. In this example, when an order is entered in the ordering interface application, the hub publishes the order to each of the other applications in the network. The accounting application monitoring the network may capture the order information transmitted by the hub to store it for future action. Upon receiving the order information, the inventory database application may reduce the inventory a corresponding quantity and publish the reduction to the hub. The accounting application, with receipt of the inventory publication from the hub, now knows that the order can be fulfilled and then uses the order information previously received to credit the ledger.
However, the shipping application may not be activated by the order information inherently received from the hub. Instead the shipping application waits for information from the inventory application before initiating shipping arrangements, because if there is no product in inventory there is nothing to ship. The shipping application may then publish shipping costs to the hub, which are transmitted to all applications on the network. While the inventory and ordering applications do not need the shipping information received, the accounting application debits the shipping costs to the ledger when the shipping information is received to populate and maintain the business books. In a hub and spoke system, therefore, any information received at the hub is published to all other applications on the network, regardless of whether they have use for the information. The applications are in constant communication with the hub to monitor for relevant incoming information that indicates that they must take action. This constant publication and monitoring can result in bottlenecks in the network.
Another prior art system is a channel-based enterprise integration model as shown in prior art FIG. 7. An example using business process systems integrating accounting, ordering, shipping, and inventory modules is again depicted. In a channel model, instead of a hub operating to serve as a focal point for the distribution of incoming information, different applications subscribe to one or more channels to monitor for or to publish an event. For example, an event might be an “order entered” published by the ordering application to this channel. All other applications with an interest in an “order entered” event would subscribe to monitor that particular channel. For example, an inventory application would subscribe to the “order entered” channel in order to check the inventory database to ensure that the order entered is available in inventory. If the item ordered was available, the inventory application could publish to another channel called “fulfill order” to which a shipping application could be a subscriber. This can be a waste of significant resources in terms of processing power and bandwidth for communications. By creating specific channels for specific events, the channel model helps avoid the bottleneck drawback of the hub and spoke model. However, applications in the channel model must still maintain a constant connection with subscription channels to monitor for pertinent new information.